Communications between remote computers is enabled through the use of so-called “protocol stacks”. Applications running on remote computers do not communicate directly with each other. Instead, messages, or other communications, are sent via a protocol stacks, such as the TCP/IP (Transmission Control Protocol/Internet Protocol) stack. Protocol stacks make it easier for applications to communicate with each other. They remove the need for applications to understand the details of, for example, how data must be sent over an Ethernet connection. Instead, the application simply passes the data to the top layer of the protocol stack, and the stacks on the local and remote computers ensure that the data gets to the application at the remote end.
Protocol stacks are implemented by communications frameworks which are typically provided as part of the operating system on a computing device. A communications framework typically has an API (Application Programming Interface) which is the point through which applications gain access to the communications framework. FIG. 1 shows a communications model 101, known from the prior art, which may be used when, for example, a user wishes to send an email to a remote computer. The left hand-side of the diagram represents components running on the local computer 102, or connected to the local computer, and the right-hand side of the diagram represents components, running on, or connected to the remote computer 103. The local computer 102 has loaded thereon an email client 104 which is arranged to send and receive emails. The remote computer also has an email client 105. As noted above, these clients cannot communicate directly with each other. Instead, the email clients must send and receive messages through the communications framework which is available on the respective computers. The communications networks on each computing device include equivalent components. These components include communications framework APIs 106, 107, transport protocols 108, 109, network protocols 110, 111 and link protocols 112, 113. The communications framework APIs 5, 6 provide the interface to the communications framework. As is well known in the art, transport protocols are responsible for delivering data to, and receiving data from, applications running on a computer. In the present case, the transport protocols 108, 109 are the TCP protocol, mentioned above. Network protocols ensure that packets of data are correctly delivered from one endpoint to another. In the present case, the network protocols 110, 111 are the IP protocol, also mentioned above. Link protocols are responsible for delivery of data between adjacent nodes in a network and depend on the bearer technology being used. For example, link protocols include Ethernet, IEEE 802.11 link layer protocols and GPRS (General Packet Radio Service).
At the bottom of the stack are bearers 114, 115, the type of which depends on the hardware 116, 117. For example, if a computer is connected to the Internet via a WiFi™ access point, then the hardware is a WiFi™ adapter, and the bearer is a radio access bearer which is established over the air interface between the computer and the access point.
Before a message is sent, the communications framework establishes a particular set of protocols depending on the application concerned, the request from the application and the available communications hardware. If a user wishes to send an email from a mobile phone, a cellular connection (for example via 3G) will be established as well as the necessary set of protocols required to send data over the 3G connection. A message may then be sent over the communications stack which has been established.
Ordinarily, the communications stack is static and persists for the lifetime of the connection. A particular set of protocols is established over a particular connection and the required communication takes place. The communications stack is then torn down. There is no mobility in this scenario as mobility is not required. In other words, all layers of the communications stack provide what is required of them and there is no need to substitute one layer for another.
However, in some situations mobility is required in the communications stack. FIG. 2 shows a mobile phone 201, which is connected to a WiFi™ access point 202. In this scenario, the user of the mobile phone 201 is browsing the Web using a Web browser. The communications framework on the phone 201 has established the necessary protocols for this process to take place. If the user becomes mobile in the direction of arrow 203, the phone 201 moves out of the area of coverage 204 of the WiFi™ access point 202. In order for the user to continue browsing the Web, the communications framework must establish an alternative connection. This can be done by breaking the connection and then re-establishing it over a different bearer. However, it may be more desirable to do this within the communications stack, using some mobility mechanism that keeps the original connection undisturbed as far as the client application is concerned. This particular scenario would require mobility at the link layer of the communications stack. In FIG. 2, the communication framework loaded on phone 201 is not capable of mobility. In the scenario shown in FIG. 2, the connection with the WiFi™ access point, and hence the connection to the Web, would be lost.
Systems are currently being developed which allow mobility in the communications framework. Generic Access Network (GAN) is one such system which is being developed and which enables a connection to remain active when a user moves away from, for example, a WiFi™ hotspot to an area which is only covered by the mobile telephone network (or vice versa). This requires a switch in the link layer protocols being used by the communications framework. The communications framework is required to maintain a connection while transferring that connection from, for example, IEEE 802.11 link layer protocol to a cellular link layer protocol such as 3G.
Such systems allow mobility at the link layer of the communications stack (e.g. between WiFi™ and GPRS protocols). Known systems are not able to provide mobility at any arbitrary layer in a protocol stack.
The aim of mobility is to offer increased connection duration to a device user. The requirement for mobility has dramatically increased recently as a result of smaller and more complex computing devices. Such devices have a wider range of technologies available for them to use for communication. As a result, the number of possible protocols which may be supported at any level of a communications stack has increased. For example, standards such as Voice Call Continuity (VCC) require mobility of a voice call between a Circuit Switched Data (CSD) protocol stack and a Voice over IP (VoIP) stack. At the same time there is a desire to make the operation of the communications framework transparent to users. There is therefore the need for a more flexible communications framework which is able to support mobility at any level of the communications stack.